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Foreword 



This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Real time, character by character text conversation is a component that can be of value in a distant conversation. Users 
may have an interest to use real time text conversation alone or in any combination with voice and video. 

Global Text Telephony is a feature that adds the capability to use a text conversation component in a session. It is called 
GTT here. 

GTT is defined in a set of host environments, circuit switched as well as packet switched. 

Interworking with corresponding features in other networks is an important part of Global Text Telephony. Specifically, 
the different kinds of PSTN text telephone systems supported by the international text telephone modem standard 
ITU-T Recommendation V.18 [4] are included in the modes for interworking consideration. 

One important reason to offer the Global Text feature is to enable emergency service access to people who are 
depending on a written dialogue. 

A more elaborated background is found in TS 22.226 [3], Global Text Telephony, Stage 1, Annex A. 
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Scope 



This 3GPP Technical Specification defines the stage 2 description of the real time Text Conversation Feature called 
Global Text Telephony, GTT. GTT Stage 2 identifies the functional capabilities needed to support the service described 
in GTT Stage 1. 

This TS contains the core functions for a real time Text Conversation Feature GTT, to be used in combination with 
other media in conversational services. 

GTT offers real time conversation in text, to be used alone or in combination with other conversational media, and 
interworking with current and emerging text conversation features in the fixed networks and other mobile networks. 

GTT uses a number of functional entities to realise the requirements of the stage 1 description (TS 22.226 [3]). This TS 
describes how the service requirements are realised with these functional entities. As far as possible existing protocols 
shall be used for the realisation of the Global Text Telephony Feature. This may include e.g. , SIP, 3G.324, or Circuit 
Switched Voice service as protocol environments, and CTM, ALl and RTP/text as transmission protocols. It also means 
usage of existing text presentation format ITU-T Recommendation T.140 [5], common to all GTT text conversation 
environments. 
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3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the following terms and definitions apply. 

Total Conversation: A service offering standardised simultaneous text, video and voice conversation or a subset 
thereof (see ITU-T Recommendation F.703 [13]). 

Host environment: The session environment where the text component is added, e.g. Circuit switched voice, IP 
Multimedia, etc. 

Text Conversation: A real time conversation in text with transmission character by character as entered. 



3.2 



Abbreviations 



For the purposes of this document the following abbreviations apply in addition to those defined in TS 22.226 [3]: 

GTT Global Text Telephony 

CTM Cellular Text telephone Modem, as specified in TS 26.226 [12] 

BCSM Basic Call State Model 

CAMEL Customised Application for Mobile Enhanced Logic 

CAP CAMEL Application Protocol 

CLIP Calling Line Presentation 

CPC Calling Party Category 

GMSC Gateway MSC 

HPLMN Home PLMN 

ISUP ISDN User Part 

MSC Mobile Switching Centre 

MSRN Mobile Station Roaming Number 

NDC National Destination Code 

PLMN Public Land Mobile Network 

SK Service Key 

TRAU Transcoder and Rate Adaption Unit 

UMTS Universal Mobile Telecommunication System 

VLR Visited Location Register 
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4.1 



General Functions 
Overview 

Fixed textphone user 

y//^ J Cellular Network 

Mobile, ^^ 

text capablej/^ 

terminals^^ { 



Fixed multimedia user 





IP textphone or multimedia user 



Figure 1 : General view of GIT feature provision within the different networl<s 

Figure 1 shows a generalised view of the Global Text Telephony feature architecture for a third generation conversation 
service system. It shall combine different networks and network types and shall integrate text conversation systems 
already existent within these networks. 

Global Text Telephony is a 3GPP Feature that can be included in 3GPP conversation services such as circuit switched 
voice telephony, circuit switched multimedia and IP multimedia conversation. It makes use of the infrastructure of the 
host environment and includes elements necessary for GTT in these environments. 

The following description and figures describe the text specific parts and leave out many details of the host environment 
conversation service where text is included. 

4.1 .1 General text transmission functions 

On the route from user to user, the text passes a set of functional elements. 
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Figure 2: Call flow for two mobile terminals with the same GTT transport method, using text 

conversation 

Figure 2 shows the function chain when communicating within the network, between terminals operating in the same 
mode. 
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Figure 3: GIT general text transmission functions showing interworking 

The view in figure 3 is applicable to transport mechanisms and network environments when communicating in 
interworking mode between different environments. 

4.1.2 Functions 



4.1.2.1 



Call Control and text media initiation 



Before text conversation can begin, a call must be established. That is done with general call control functions of the 
host environment. GTT Elements detect the desire to establish a text channel, select a suitable transport mechanism, and 
activate transmission functions. 



4.1.2.2 



Presentation coding 



The text in GTT shall be coded in a common presentation protocol, ITU-T Recommendation T.140 [5]. If necessary this 
presentation protocol shall be converted to or from any legacy mode character code used in other networks. 



4.1.2.3 



Transport and transmission host environments 



When text transmission is activated, a suitable transmission method in the PLMN is selected. The appropriate method to 
use is selected according to the call environment. The environments vaUd for GTT are called GTT Host environments: 

1. IP Multimedia, according to IPMM subsystem with IETF RFC 3261 [11] (SIP). 

2. Circuit Switched Multimedia according to 3G.324. 

3. Circuit switched voice channel. 

Other methods to establish real time text conversation exist and may be used without further standardisation, using 
basic communication services of the PLMN. One example: 

Digital data transmission in a data channel can be used for real time text conversation. For cases 
when only text conversation is wanted, there are a multitude of ways to implement that kind of 
communication. It can for example be done through a HTML based server, with an already 
established mainstream mechanisms that do not require text conversation specific functions to be 
stored in the terminals. An alternative may be to use GSM circuit switched data functions for text 
telephones that are compatible with the modem characteristics provided. 



4.1.2.4 



Multiplexing 



The text transport is multiplexed in the network and radio interface according to normal procedures for the selected host 
environment. 
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4.1.2.5 Conversion 

For text conversation with text telephones and text capable terminals in different networks or using different transport 
mechanisms, conversion functions may be used. Functions and procedures suitable for the conversion functions are 
described in ITU-T Recommendation H.248.2, packages for Text telephony, Text Conversation and Call Type 
Discrimination [9]. 

4.1.2.6 Text capable terminal 

By using the described GTT functions, a real time text conversation session can be conducted between GTT supported 
mobile Text Capable Terminals.. Different terminal function combinations and GTT host environments give different 
opportunities regarding combinations of text with voice and video. Valid combinations are: 

text only, 

alternating text and voice, 

simultaneous text and voice, 

simultaneous text and video, 

simultaneous text, video and voice. 

4.1 .2.7 Routing and location of CTM detection/conversion functions 

There are three ways to include conversion functions between legacy text telephony and CTM. 

The 'All transcoder solution'. 

The CTM detection/conversion can be carried out within the transcoder function or within a separate node 
associated with the transcoder function. This approach means that no specific routing is required since the CTM 
detection/conversion function will be present in every speech call. Further explanations are found in Annex A. 

The 'CTM circuit pool solution'. 

The CTM detection/conversion function can be located in a dedicated resource pool in the access network or can 
be associated with transcoders in the core network. In these cases, the MSC/MSC Server requires an indication 
from the terminal that this CTM detection/conversion function is required. See TS 24.008 [16] for the definition 
of this indication. This indication provides the necessary information to invoke the CTM detection/conversion 
function. TS 48.008 [15] defines mechanisms for pool identities and selection. Further explanations are found in 
Annex B. 

The 'CTM-SRF core network node solution'. 

The CTM detection/conversion function can be placed in the core network as a separate CTM Special Resource 
Function (CTM-SRF), in which case routing functions are required to make sure calls are routed via the CTM- 
SRF for CTM detection/conversion. Routing can for example be based on subscriber data or specific call 
conditions available for MSC routing, e.g. emergency calls. Further explanations are found in Annex C. 



4.1 .3 Emergency service considerations 



If an operator implementing GTT selects to offer access to Emergency Services through this feature for a specific host 
environment, the following must be considered. 

If the emergency services only has limited types of text conversation devices, conversion from the users host 
environment to the one used by the emergency service may be configured. 

If the calling party address and location information are provided in voice emergency calls, this information must be 
preserved also in text emergency calls, and not changed by any conversion or routing mechanisms introduced. 

Other host environment specific considerations for emergency calls are described in sections below. 



£75/ 



3GPP TS 23.226 version 10.0.0 Release 10 



11 



ETSI TS 123 226 VI 0.0.0 (2011-03) 



Considerations for each host environment 



5.1 



GTT-IP: IP Multimedia 



5.1.0 GTT-IP 

IP Multimedia, supported by the IPMM subsystem, is a suitable environment for real time text conversation. GTT-IP 
stands for the Text Telephony in IMS via the Real-Time Text protocol over RTP. It shall use IETF SIP [11] for the 
negotiation of the text media and IETF RFC 4103 [10] RTP -text for transport, with text coded according to ITU-T 
Recommendation T.140 [5] as indicated in TS 26.235 [14]. This allows conversation in a selection of simultaneous 
media, such as voice, text and potentially also video. 

Inclusion of the text conversation shall be done according to normal SIP and IPMM procedures, where the text media 
stream is handled as any other media. GTT-IP has no architecture influence on the 3G-PS network, only that the 
components must allow handling of the standardised text media stream. 

NOTE: This way of using mainstream procedures opens possibilities to utilize the flexibility of the SIP protocol 
for enhanced services. The user can interact in the service offering to optimise the stream handling. This 
may be used for flexible ways of invoking relay services for media conversion according to the desire of 
the users. 

5.1 .1 Interworking between Real-Time Text and PSTN Text Telephony 

Interworking between Real-Time Text (RTT) and PSTN text telephony is provided by introducing conversion in the 
IMS-PLMN between IP-based Real-Time Text via RTP and modem based transmission of real-time text using ITU-T 
Recommendation V.18 [4] or any of its specific sub-modes. See TS 26.114 [17]. 

The conversion function can be seen as a context containing a Text/RTP termination plus a voice/RTP termination and 
an ITU-T Recommendation V.18 [4] text telephony termination with multiplexed V.18 and voice via PCM. 

It can be symbolically documented as follows. 



Text/RTP 



Voice/RTP 



PS-Client 




V18/PCM 

+ 
Voice/PCM 



legacy TTY phone 



Figure 5.1 .1 .1 : Interworking with PSTN 



If the mobile terminal requests Real-Time Text telephony, the call shall be setup with the RTT media type in parallel to 
the voice media, and the MGCF / IMS-MGW shall insert the Interworking function between RTT and V.18. On the 
contrary, if the mobile does not request RTT support, no Interworking function is necessary (which would represent 
majority of calls). 

Functional details of the interworking between Real-time text and PSTN Text telephony are specified in 
TS 29.163 [18]. 

5.1 .2 Emergency call considerations for GTT-IP 

Regional regulatory rules may require the capability to let a user use any Real-time text capable mobile terminal for a 
text call to emergency services on the PSTN. This is an example of interworking from Real-time text to the PSTN. 
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Depending on local regulation and operator's policy, it may also be required to support emergency calls originated by a 
SIM-less UE or a UE without a valid subscription. In these cases RTT / V.18 interworking shall be supported as in case 
of emergency calls for UE with a valid UICC. 

Call back from emergency services is handled as Mobile Terminating calls as specified in clause 5.1.1. 

5.2 GTT-CS: Circuit switched IVIultimedia 

Text conversation in Circuit Switched Multimedia is called GTT-CS. The host environment is 3G.324, according to 
TS 26.1 10 [6] Codec for circuit switched multimedia. GTT-CS Text is ITU-T Recommendation T.140 [5] coded and 
transported in an ALl channel. Any combination of Video, Text and Voice can be supported and used simultaneously. 

GTT-CS has no architecture implications on the 3G network, only that the network components must allow the 
standardised handling of the text media channel as well as any other media channel. 

5.3 GTT-Voice: Circuit switched voice channel 

Voice channel transmission of text shall use CTM; Cellular Text telephone Modem, TS 26.226 [12]. It is possible to 
alternate between text and voice. Text shall be coded according to ITU-T Recommendation T.140 [5] on the 
presentation level. 

5.3.1 Interworking between GTT-Voice and PSTN Text Telephony 

If GTT-Voice is provided, interworking to PSTN text telephony can be provided by introducing conversion in the 
PLMN between CTM and PSTN based text telephony using ITU-T Recommendation V.18 [4] or any of its specific 
sub-modes. 

A simple extension can be made of the conversion functionality described in H.248.2 [9]. CTM is included among the 
transport mechanisms by an extension of package txc. 

For the CTM and PSTN text telephone case, a conversion function can be seen as a context containing a CTM 
termination and a ITU-T Recommendation V.18 [4] text telephony termination. This combination is called the CTM 
channel. It is foreseen that the CTM channel need control to be initiated to the proper state for each call etc. Such 
functions are here collected in an entity called interworking control. 

The CTM channels are normally transparent but monitoring for text telephone signals or CTM signals. When a signal is 
discovered, the audio path is stopped and character conversion and transmission performed. 

It can be symbolically documented as follows. 
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Figure 4: Interworking with PSTN 

Since the PSTN text telephone protocols have states, resetting the state during the call should be avoided because it can 
cause loss or corruption of characters, loss of communication or a long ITU-T Recommendation V.18 [4] handshake 
before reestablishment. 

For the CTM-SRF core network node solution, already standardised routing and invocation mechanisms should be used 
to invoke CTM detection/conversion in the calls that may require text conversation. 

The mechanisms for invocation of the CTM channel act on both Mobile Originating calls and Mobile Terminated calls. 

5.3.2 Functional details of fixed network interworking 

The default action of the call path in the CTM-detection/conversion function is to transfer audio transparently while 
monitoring for text telephone signals. When valid text telephone signals are detected, the converting action of the 
channel takes effect. The path converts between the detected PSTN text telephone method and CTM. This mode of 
operation continues until text signalling ceases. Then transparent audio transport is re-established, again monitoring for 
text signals. This way of action allows alternating use of text and voice during the call according to established 
conventions in text telephony. 

TS 26.226 [3] describes the details of CTM and an indication of how CTM can be combined with a text telephone 
modem to compose a conversion function in the call path. 

ITU-T Recommendation H.248.2 [9] describes the principles of conversion between PSTN Text telephony as in the text 
telephone ITU-T Recommendation V.18 [4] and any general real time text conversation feature. So, even if CTM is not 
mentioned in that Recommendation, its general descriptions are valid for this case. On the PSTN end it is valid also for 
specific sub-modes of ITU-T Recommendation V.18 [4] (Including the US method Baudot 45). The handling is slightly 
different depending on if the selected ITU-T Recommendation V.18 [4] sub-mode is carrier-based or carrier-less, and if 
the call is known to be with a textphone or being general. 

The descriptions in ITU-T Recommendation H.248.2 [9] can be taken as functional descriptions of the call path without 
full implementation in a H.248 environment. 

5.3.3 Emergency call considerations for GTT-Voice 

It may be required to let a user use any CTM capable mobile terminal for a text call to the emergency service. If a 
terminal can support CTM and establishes a call with the CTM active then it will be expected to provide the network 
with an indication that a CTM detection/conversion function is required in the network. 
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It may be required to handle emergency calls also when the call comes from a SIM-less phone or a phone with an 
invalid subscription. To meet this requirement, one configuration option, when the CTM-SRF is used, shall be to route 
emergency calls independent of subscription status through the CTM detection/conversion function. 

If the terminal supports CTM and is SIM-less, then it will be expected to indicate to the core network that CTM 
detection/conversion is required in the network. 

Call back from emergency services is handled as normal Mobile Terminating calls. 

5.3.4 Interworking aspects 

The following are known interworking issues between the different circuit switched voice solutions, and these should be 
considered carefully before deploying different approaches within one PLMN or regulatory area: 

It is critical that all mobile terminals requiring CTM detection/conversion indicate to the network when CTM is 
required, otherwise a network that has adopted the CTM circuit pooling solution will not be able to allocate the 
appropriate CTM capable circuit. This CTM indication should therefore be considered a mandatory terminal 
requirement. 

An indication from a mobile terminal that CTM detection/conversion is required will not result in any 
interworking issues if the indication is received by a network where all the transcoders are CTM capable or 
where a core network CTM-SRF solution has been chosen. This is because the indication is redundant in this 

case. 

If a subscriber, from a network where all the transcoders are CTM capable or a CTM circuit pooling solution has 
been adopted, roams to a network where a core network CTM-SRF solution has been chosen, then the subscriber 
will only receive CTM conversion for emergency calls. The reason is that the subscriber lacks the necessary 
subscription to a CAMEL service, which would route this normal call via a core network CTM-SRF. 

In the case where inter-MSC handover occurs between an MSC where all the transcoders are CTM capable or a 
CTM circuit pooling approach is in operation, and an MSC which relies on a core network CTM-SRF, then the 
subscriber will lose CTM conversion for all calls. 

If a subscriber from a network where a core network CTM-SRF solution has been adopted roams to a network where all 
the transcoders are CTM capable or a CTM circuit pooling solution has been chosen, then the subscriber will receive 
CTM conversion for all calls. The presence of two CTM detection/conversion functions in tandem should not create any 
interworking issues. 
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Annex A (informative): 

GTT-Voice specific information for CTIVI support in, or 

associated with, all transcoders 

A.1 GTT-Voice specific information for CTM support in, 
or associated with, all transcoders in the access 
network for GSM networks with A-interface 

The CTM detection/conversion function may be incorporated in all transcoders where CTM activity can realistically be 
expected. It is also an option to incorporate a CTM detection/conversion function in a separate entity associated with the 
Transcoder. 

The CTM adapter automatically detects the presence of CTM encoding and provides the necessary conversion to the 
appropriate ITU-T Recommendation V.18 [4] modem encoding. 




BSC/ 
Transcoder 




Figure A.1 : Association of a CTIVI adapter with the transcoder in the access network 

Due to the presence of the CTM detection/conversion function in all circuits, no CTM capability information needs to 
be signalled to the network by the mobile. 



A.2 GTT-Voice specific information for CTM support in or 
associated with all transcoders in the core network 
for networks supporting the lu interface 

For networks with GERAN and UTRAN radio access using the lu interface, the CTM detection/conversion function 
may be incorporated in all transcoders where CTM activity can realistically be expected. It is also an option to 
incorporate a CTM detection/conversion function in separate entity associated with the Transcoder. 

The CTM adapter automatically detects the presence of CTM encoding and provides the necessary conversion to the 
appropriate ITU-T Recommendation V.18 [4] modem encoding. 
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Figure A.2: Association of a CTIU! adapter withi tlie transcoder in tlie core networl< 

Due to the presence of the CTM detection/conversion function in all circuits, no CTM capability information needs to 
be signalled to the network by the mobile. 
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Annex B (informative): 

GTT- Voice support via selection of CTIVI detection / 

conversion function 

B.1 GTT- Voice specific information for CTIVI support in 
GSM networks with A-interface, via access network 
circuit pooling 

A-interface pooling, and routing to a selected pool, is an intrinsic capability within current GSM Networks and is used 
to select transcoding for EFR, FR and in future AMR. It is an option to create circuit pools on the A-interface, which 
support the CTM detection/conversion. The circuit pools are defined in TS 48.008 [15]. These pools may be 
incorporated in the transcoder, in a separate entity associated with a transcoder or in a separate entity located in 
particular A-interface circuits but remote from the transcoder. 

The main steps of the process for a mobile originated call are: 

Setup from terminal, including CTM indication. 
MSC detects CTM indication and allocates a circuit with CTM capabilities. 
The main steps of the process for a mobile terminated call are: 
- Setup from MSC. 

Call Confirm from terminal including CTM indication. 
MSC detects CTM indication and allocates a circuit with CTM capabilities. 




BSC 



Transcoder 

Circuit 

Pool 

CTM 
adapter 




Figure B.I : CTM adaptor contained within a transcoder pool 
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Circuit where CTM 
detection/conversion is 
not available 




Figure B.2: CTM adapter present on specific A-interface circuits 



B.2 GTT- Voice specific information for CTIVI support via 
core network termination selection for networks using 
lu interface 

For networks with GERAN and UTRAN radio access using the lu interface, a method to allocate the calls to 
terminations capable of handling CTM on audio channels can be provided in the core network. It can be based on the 
mechanisms for controlling Media Gateway functions through the control language specified on the Mc interface. The 
MSC Server has information on CTM indication issued by the mobile station and allocates terminations with proper 
CTM capabilities for the detection/conversion during the call. 

The main steps of the process for a mobile originated call are: 

Setup from terminal, including CTM indication 
MSC server detects CTM indication and allocates a termination with CTM capabilities in the Media Gateway. 
The main steps of the process for a mobile terminated call are: 
- Setup from the MSC Server. 

Call Confirm from the terminal including CTM indication. 

The MSC server detects CTM indication and allocates a termination with CTM capabilities in the Media 
Gateway. 
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Figure B.3: Association of a CTIV! capable termination within the IVIedia Gateway 
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Annex C (Informative): 

GTT- Voice specific information for the CTIVI-SRF core 

network node solution 

This section describes a method how to route possible text calls via a core network node called the CTM-SRF. It should 
be taken as an informative example. It is based on CAMEL Phase 1 and call signalling with ISUP. Other call control 
environments and other IN service platforms can accomplish the same result. 

This section shows how emergency calls, terminating calls and originating calls can be routed through the CTM-SRF 
node without any modification to existing core network nodes. This covers also mobile-to-mobile calls. 

For cases where emergency call support for text calls is wanted, all emergency calls are routed to the CTM-SRF server. 
The CTM-SRF server routes the call to the emergency centre. This can be done, as the CTM/textphone conversion 
channel itself is transparent to speech. 

Originating and terminating calls, from and to possible text telephone users, are handled as CAMEL calls. A CAMEL 
service assures that the calls are routed through the CTM-SRF node by actions of a CAMEL application. 



C.1 Emergency calls 



The network has no means to distinguish text emergency calls from voice emergency calls in areas where the same 
number is used for both types. It may also be desired that even a phone borrowed for the purpose of making a text 
emergency call shall get the text service without any specific text subscription. Therefore, in order to meet these 
requirements, it shall be possible to configure the network to route all emergency calls through CTM-SRF server nodes. 




Figure C.I : Emergency call routing 

If the emergency service use the same number for emergency text calls as for emergency voice calls, routing of all calls, 
regardless of text or speech, to a CTM-SRF server can be accomplished by configuration in the MSC/VLRs. The 
MSCA'^LR can be configured in a way that, depending on the Emergency Centre addresses, emergency calls are always 
routed via a CTM-SRF server. 

The CTM-SRF links in the CTM/textphone conversion function and routes the call further according to the received 
lAM. 

The CTM-SRF node could recognise emergency calls by knowing all numbers of the emergency centres in question. 

For US E-91 1 -calls an additional method is given by looking at the CPC field. A special value is given. 
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CPC 'H'EO" represents "emergency service call". 
In general, the CTM-SRF server handles emergency calls in the same way as normal Mobile originated calls. 



C.2 Routing of regular user calls 

Regular user calls that may contain text are routed to the CTM-SRF by a CAMEL service. 

Text users are identified by a Text Telephony CAMEL Service Key (SK) and other CAMEL information stored in the 
HLR. The CTM part of this service modifies the Called Party Address (see following chapters). The call is routed 
through the CTM-SRF server and is then routed to the original destination. 



C.2.1 Mobile Terminating calls 




Figure C.2: Paths for routing of mobile terminating text calls with call path shown in thick arrows 

The GMSC discovers that the user is a subscriber of the text telephony service, by the Camel Subscription Information 
information received from the HLR. The text Service Key is present and the Detection Point = 
Terminating_Attempt_Authorized. 

The SCP with the text telephony service application is connected and the routing of the call through the CTM-SRF node 
is performed. 

To control the activation of CAMEL service invocations an indication is sent from the CAMEL service via the CTM- 
SRF server back to the CAMEL service. This information is used by the CAMEL CTM-SCP service (2"'' invocation) to 
do nothing but just to continue the call. 

The indication is carried in the Calling Party Category parameter of ISUP. 

This ISUP parameter is supported in CAP VL InitalDP, and Connect. The CTM-SRF node and the CAMEL CTM-SCP 
service form an integrated application, and this ISUP parameter handling is regarded internal application signalling. 



Figure C.3: Mobile Terminating Text Call 

For the support of text users, the CAMEL CTM-SCP service will return the textphone-number with a CTM-SRF server 
prefix in CAP_CONNECT. The GMSC creates a new O-BCSM for this CAMEL based forwarding leg. It uses the 
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Destination Routing Address in CAP_CONNECT to do the routing and to send the ISUP_IAM. The routing is based on 
the CTM-SRF server prefix part. 

The CTM-SRF server Hnks in the CTM/textphone conversion function and extracts Text subscriber address, Nature of 
Address, and the Numbering Plan Indicator from the Destination Routing Address parameter. It stores the original CPC 
value in Additional Calling Party Number parameter. If Called Party"s Category is not received, then this information 
as such is encoded. It writes this information to the appropriate lAM parameters and routes the call to a GMSC. It could 
be the same GMSC as before or a different one. 

The GMSC regards this incoming lAM as a new terminating call to a text subscriber. A second time a dialogue for the 
'same text call' to a CAMEL service is invoked. The service realises this fact and does nothing but connecting the call to 
the Text subscriber (Called Party Number, respectively Destination Routing Address has not been changed by the 
CTM-SRF server). 



C.2.2 Mobile originating calls 




Figure C.4: Mobile originating call routing overview 

The following sequence chart shows the mobile originating traffic case. 
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Figure C.6: Mobile Originating Text Call 

For normal originating calls the MSC finds the CAMEL text telephony Service Key in the VLR, together with 
information on the Detection Point = Collection of dialled digits. All non-emergency calls for the user will cause a 
connection to the text telephone service application in the CTM-SCP. The A-category value from the subscriber data in 
the VLR is used as CPC value. 

The CAMEL service knows that it is an originating call. In this case it just forwards the Calling Party"s Category 
parameter untouched. 

The CTM-SRF removes its own address digits from the Called Party Address. The CTM/Text telephone conversion 
function is inserted before the call is routed towards the B-subscriber. 

C.2.3 Mobile to Mobile Calls 

Two CTM-SRF servers are linked in, one on the originating leg and one on the terminating leg. The originating 
ISUPJAM sent from the CTM-SRF server on the outgoing side is received by the GMSC as normal ISUPJAM. 



C.3 Routing actions of the CTIVI-SCP 

From the sections above, it can be derived that the following actions are performed in the CAMEL server CTM-SCP 
acting on the CAP Interface. 
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Additional Calling Party 
Number = Calling Party 
Category = "CTM" 



Calling Party Category 
= Additional Calling 
Party Number 



Destination Routing Address = 
CTM-SRF (V.18 side)+original 
Called Party Number 



Additional Calling 
Party Number = Null 



CAP_CONNECT 



CAP_CONNECT 



Figure C.7: CTM-SCP Logic for IVIobile Terminated case. Detection point =Terminating Attempt 

Authorized 





\ CAP_INITIAL_DP 










Destination Routing Address= 
CTM-SRF(CTM side) + 
original Called Party Number 








> 




CAP_CONNECT \ 



Figure C.8: CTI\/!_SCP logic for Mobile Originated case at detection point=Collection of dialled digits 
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C.4 Routing actions of the CTIVI-SRF 



ISUP lAM 



Copy all lAM information to 
outgoing lAM, 
strip CTM-SRF number from 
Called Party Address in 
outgoing In lAM message 



Connect incoming to V.18 side 
of CTM Channel 
Connect outgoing to CTM 
termination 



ISUP-IAM 



Figure C.9: Routing logic in CTM-SRF for Mobile terminated calls 
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ISUP lAM 



Copy all lAM information to 
outgoing lAM, 
strip CTM-SRF number from 
Called Party Address in 
outgoing lAM message 



Connect incoming to CTM side 
of CTM Channel 
Connect outgoing to V.18 
termination 



ISUP-IAM 



Figure CIO: Routing logic in CTM-SRF, for Mobile Originated calls 
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C.5 Service interactions 

C.5.1 Interaction with other CAMEL services 

The text users can use other CAMEL services. However, with other CAMEL services using the same Detection Point as 
the Text Telephone service, the other CAMEL services are impacted when using CAMEL Phase 1 as presented in this 
document. 

As for the impact on existing CAMEL services, some of the services may be impacted anyway to support text users, for 
example Prepaid for playing announcement in text telephone signals. 

Every CAMEL service, which is expected to be used by both voice and text users, and use the same CAMEL detection 
point as the GTT service, is assigned two SKs, one for non-text users and another for text users. For text users the other 
service logic has to integrate CTM-SCP routing logic. 

C.5.2 Interactions with Supplementary Services 

In general, no other interactions are expected than described in the CAMEL standard. 

Call Forwarding in GMSC is invoked after terminating CAMEL service invocation. This means the CTM-SRF service 
node is already linked in the call path. A further invocation of a mobile originated CAMEL based service will cause an 
additional routing to a CTM-SRF service node. This is needed to convert the text back to text telephone coding, e.g. 
Baudot, which is required for the following routing towards the forwarded-to-party (C-party). 



C.5. 3 Emergency Call interaction 



New emergency call categories introduced in 3GPP Release 4 (introduced as emergency-call enhancement) have no 
impact on routing of emergency calls via CTM-SRF server. 

New categories may be specified in order to detect text emergency calls. 

C.5. 4 Usage of Destination Routing Address 

The Destination Routing Address CAMEL parameter is used by the service logic for two purposes. 

- It contains the CTM-SRF server address to let the MSC to route the call to the CTM-SRF server. 

It contains the original B-subscriber address, to let the CTM-SRF server to use it as Called Party Number on the 
outgoing side. 

When the service logic reconnects the CTM-SRF server, the service has to save the Nature of Address and the 
Numbering Plan Indicator of the original Called Party Number in the Destination Routing Address parameter. 

CAMEL Phase 1 Destination Routing Address has up to 12 octets. Two octets are needed to encode Nature of Address 
and the Numbering Plan Indicator. This means that 10 octets are left for CTM-SRF server address digits plus Called 
Party Address digits. All together 20 digits are given. 

An international one up to 15 digits according E.164. This results in having 5 digits left for CTM-SRF server 
addressing. 

C.5. 5 Inserting CTM/Text telephone conversion function 

The CTM/Text telephone conversion function is direction oriented. A CTM modem should be connected towards the 
radio side and a modem for ITU-T Recommendation V.18 [4] or any of its text telephone submodes towards the other 
direction. Therefore the CTM-SRF server has to distinguish between mobile terminating and mobile originating calls. 

This can be achieved by either allocating different channels for the directions or make decision based on the Called 
number to the CTM-SRF. 
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C.5.6 Lawful interception 



Depending on where on the route the intercept is made, and also depending on the support for CTM in the terminal, the 
coding in the intercept point will be transmitted in CTM modulation and coding, or native PSTN text telephone coding 
and modulation. Both are possible to decode, and a combined decoder can be designed. 

NOTE: In some countries it is required that all PLMN specific codings are decoded before the lawful 
interception. In this case operators must upgrade their lawful interception equipment. 
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